Carrier Ethernet Networks have—amongst other requirements—the requirement to provide high availability. This is reached by avoiding outage times of the Carrier Ethernet Network Elements and Components as well as by network protection mechanisms against link failures and node failures. In the latter case, fast restoration times are necessary to be able to run Ethernet as Carrier Ethernet.
In traditional Ethernet LAN (Local Area Network) environments, Spanning Tree Protocol (STP) has been used for this purpose, guaranteeing loop-free topologies and, in case of redundant links, provide failover using previously un-used LAN segments but its slow convergence has made it nearly obsolete. With Rapid Spanning Tree (RSTP) things have improved and sub-second failover times could be reached.
However, for certain sensitive traffic types such as real-time gaming traffic or IPTV (Internet Protocol Television) traffic, even RSTP is perceived as being too slow from a convergence time point of view and the ITU-T G.8032 standard for fast Ethernet Ring protection has been developed. G.8032 promises <50 msec failover times on link level in certain situations.
A G.8032 Ethernet ring has one ring protection link (RPL), which is blocked in normal operation, thus avoiding loops. In case of a failure on a link or port, signal failure (SF) messages are multicast to inform other ring nodes of the failure condition. On protection switching, the RPL is unblocked forming a new topology and thus a new traffic pattern on the ring.
Multicast transmission is a technology of delivering information to a group of users or a group of destination computers simultaneously in a single transmission from a source to the different destinations, these destinations building a multicast group.
To be able to efficiently handle multicast traffic many switches in a carrier Ethernet environment support the IGMP snooping functionality as disclosed in “Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches,” Network Working Group Request for Comments 4541”. IGMP snooping is a feature that allows a layer to switch to “listening in” on the layer 3 IGMP conversation (IGMP report and IGMP leave messages) between hosts and routers by processing the layer 3 JUMP packets sent in a multicast network as disclosed in further detail in “Host Extensions for IP Multicasting (IGMPv1), Network Working Group Request for Comments 1112” and “Internet Group Management Protocol, Version 2 (IGMPv2), Network Working Group Request for Comments 2236”. Though violating the OSI (Open Systems Interconnection) layer responsibilities these layers 3 can be used to prevent hosts on a local network from receiving traffic from a multicast group that have not explicitly joined on a per port basis.
In this context switches build a knowledgeable table (the IGMP registration table) in order to know on which port which multicast traffic, i.e. which multicast group traffic of a multicast group, has to be sent.
In FIG. 1 an Ethernet ring is shown where the switches run G.8032 and IGMP snooping. Since IGMP Snooping is enabled, multicast traffic is only sent out on those ports that are interested in multicast traffic. Referring to FIG. 1, this means that the fully shaded circles represent the ports registered in the IGMP registration table as a port that has joint a multicast group. Multicast traffic for a specific multicast group will be forwarded on this board. The other empty circles represent ports registered in the IGMP registration table as a port that does not forward multicast traffic. Furthermore, in FIG. 1 between the ring nodes A and G two ports are blocked due to G.8032, the connection between nodes A and G representing the ring protection link RPL. In the embodiment shown in FIG. 1 multicast traffic from a multicast source 10 is transmitted through the fully shaded circles to the different hosts inter alia to host G1 and G2. By way of example, if hosts G1 and G2 have sent IGMP membership report messages to the multicast source, the respective ports on switch G are registered in the IGMP registration table of switch G. If the traffic running over an Ethernet ring is multicast traffic, then the ITU-T G.8032 standard mentioned above does not describe how to handle the IGMP registration table during a topology change in the ring, e.g. when a link failure or a recovery occurs.
FIG. 2 shows an example of a situation after a link failure in an Ethernet ring between nodes F and G, where the switches run G.8032 and IGMP snooping. The ring protection link blocked in FIG. 1 is now unblocked. If the IGMP registration table is not changed after the failure, then black holing (loss of traffic) of traffic might occur, since the hosts G1 and G2 will not receive multicast traffic any longer.
G.8032 node A does not have an entry in its IGMP registration table on the port direction G.8032 node G. Thus, no multicast traffic will be forwarded on this ring port. Hosts G1 and G2 have received the requested multicast traffic via G.8032 node F before the link failure. Now, they would need to receive this traffic via G.8032 node A. In order to update the IGMP registration tables of the involved nodes, host G1 and G2 would need to issue a new IGMP report to receive again the multicast traffic via the new topology.
Other protection protocols have been described how to handle multicast traffic after a 30 topology change. By way of example, it is described in “Cisco 1OS Software Configuration Guide—Release 12.1 (12c) EW: Understanding and Configuring IGMP Snooping Filtering” to either flood multicast traffic on all or selected VLAN ports dependent on node configuration: here, all IGMP registrations are deleted and multicast traffic will be flooded on selected ports for a configurable amount of time. Flooding will continue until the mechanism to prune multicast traffic from links that do not contain a multicast listener is kicking in via IGMP snooping. In an alternative, multicast traffic is not flooded at all. In this embodiment, traffic outages occur until the interested hosts send new IGMP report messages.
Both options have disadvantages:
For the first option, traffic will be flooded unnecessarily and since this happens during a failure event, the network is even more sensitive to high amounts of traffic.
For the second option, the traffic outage on service level is well above the failover times of the transport network—which might be −50 msec in case of G.8032.
IGMP Query Solicitation is a feature that allows switches to force an immediate general IGMP Query by the Multicast Source Router.TR-1 01, as disclosed in “TR-1 01, Migration to Ethernet Based DSLAggregation”
Upon detecting topology changes (e.g. VLAN membership change, port being disabled by STP or network port changing state), the Access Node MUST be able to issue an IGMP proxy query solicitation, i.e. an IGMP Group Leave with group address ‘0.0.0.0’. This will indicate to the BNG (=Multicast Source) it immediately needs to send Group Specific queries, which will populate the L2 multicast filters in the Access Node, in order to speed up network convergence.
The problem with IGMP Query solicitation feature is that                1. the feature must be available in the affected switches        2. It still takes at least 1 second to re-establish the multicast path        
All of the above stated existing solutions either lead to                unnecessary multicast traffic flooding or        black-holing or        a multicast service restoration time not in the range of 50 ms as G.8032 provides on physical connectivity level.        